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Abstract 

Computers are unique in their ability to be programed 
for a vide variety of applications. This is in contrast 
with hardware dedicated to specific tasks such as the 
telephone systen. Because of its flexibility, a computer 
systen can support, concurrently, nany diverse services 
that do not require dedicated hardware. Conversely, these 
services act to bring the capabilities of the computer to 
the consuner who light otherwise find the operational 
difficulty of running computer progress too formidable. 

Since the conputer is supporting nany services which 
are sold to consumers it is natural to nodel the systea as 
a narketplace for these services. Most contemporary 
conputer systens are oriented towards users who run 
prograas. The environnent for services pats different 
requirenents on the conputer systens than do the needs of 
progranners, so as to per ait all the participants in the 
narket to nake effective use of its facilities without 
requiring dedicated facilities and without interfering with 
each other. As with any narketplace, it aust be convenient 
to do business within its f ran e work. 

The reguireaents of such a narketplace are not 
satisfied in conteaporary ccnputer systens. However, the 
narketplace cen be ^eVdi%etf ' ; <f*en ';-'*©•» e*is*dag conputer 
systens without fundanental changes .n P r e eent ly the use of a 
ccaputer requires considerable expertise vntotluMart of the 
user. The evolution €0 * r, %arli*Pupl«:e.j4*-«ecessary if the 
capabilities of conputer systens are to be nade aore widely 
available than they are now. 
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CHAPTER ONE 
INTRODUCTION 

Computer systems have evolved from simple calculators 
to more sophisticated processors capable of running complex 
programs with large data bases, to information systems 
serving the diverse needs of many users. Despite the 
evolution of hardware and software in the past twenty five 
years, computers are still regarded by many as esoteric 
devices for solving well-defined problem*, one approaches 
the computer with a problem, programs the machine (or uses 
an existing program) , feeds in data and the Computer prints 
the results. This mode of operation* is being superseded by 
one in which the roles of the compute* and the user ace not 
as well-defined, where the user works with the computer to 
find the solution to a problem. Even the idea that one must 
necessarily have a specific problem in mind is being 
replaced by the view that a computer ofifers a collection of 
programs ^which one may call upon (through a command 
language) to perform tasks when reforested* The tasks may be 
one of those traditionally associated - .»±fcii the computer -,- 
compiling, statistical analysis and ^report, generation or 
they may be used to communicate »ith one*s bank, library or 
colleagues, to manage household finances, recipes. 
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scheduling, or shopping. 

These latter applications are not conon for a naaber 
of reasons. Some of these are technical — we often do not 
have the knowledge to construct programs of the reguired 
sophistication. Hany of the difficulties are not technical, 
bat are the result of designing coaputer systeas for 
running programs. But being able to run a prograa is not 
equivalent to being able to sake effective use of a 
coaputer. The wast majority of couputer users, as opposed 
to prograeaers, should not need to be concerned with the 
details of running the programs. By concentrating on the 
coaputer as a hoae for programs one aissee the forest for 
the trees. This thesis will distinguish between the use of 
prograas and the use of services on, a coaputer systew. The 
aia is to exaaine coaputer systeas as bases for providing 
services. 

The evolution of coaputers froa prograaaing systeas to 
service systeas is siailar to the earlier evolution froa 
the bare aac nines to those with the support of 
sophisticated operating systeas with their associated file 
systeas, libraries and other resource aaaageaent 
facilities. The service environment provides the vendor 
with the facilities needed to enable hia to present his 
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services to his users without requiring knowledge of the 
complexities of the computer system. She telephone system 
is an example of a - couple z systeu dedicated to a liuited 
set of services. When placing- ,1. telephone call, a 
subscriber is using a very complicated communications 
network, but he need only state his request in terns of the 
service he is asking for. normally *hi»ei*c deae by simply 
"dialing" the number of the phone.he wishes tos be connected 
to. In addition to being shielded froac -the technical 
complexities of the phone sysfcea* he is also shielded from 
the financial complexities and the politics of dealing with 
aultiple telephone companies, ill he sees is a bill stated 
in terns of the calls that he Bade* ,1, computer system has 
much in common i with "the telephoneo system in -providing 
services to itsu mubscfibers* loweve**; while < the telephone 
systea is organized around a ; limited? set i; of -services* the 
computer system is an environment in which many diverse 
services can be offered* As the telefhoae companies-have 
found solutions to the problems ofi providing their specific 
services* the computer systems masi^ provide an environment 
that permits solutions to be applied- to a large, variety of 
services. 

To investigate the general problems of providing a 
variety of services within a computer system, this thesis 
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Introduction r. Franfcston 

provides an enhanced aachine. The most important 
characteristic of this environment is the availability of 
other services that nay interact with each other, in fact, 
the computer systea can be viewed as si ■ ply a collection of 
these services ; soae being basic, such as the computer 
hardware and file Systapu and others being aore 
sophisticated. 

& description of am* environment for offering coaputer 
based ser vices is incomplete! without iamy discussion of the 
financial or resource ■anagemoat aspects ^ * of the 
environment. In the design of computer systeas the pr Ob leas 
of buying and selling coaputer services have largely been 
dealt with in an ad hoc fashion. In aany projects such as 
the A HPA network* they have simply been deferred. But the 
viability of a coaputer systea a® a marketplace for 
services depends largely on th» ability to transact the 
business of buying and selling r tfea? services., »r© date, auch 
of the discussion of accounting for computer usage has. been 
concerned with ; the allocation. ■ of co»%s5 :^C©ra th» computer 
systea to its users and with the use? wt pricing structures 
to distribute the coaputer resources according to given 
policies. This is not, however, the a.ia ©f* a financial 
systea for a marketplace. In the; marketplace , the problea 
is one of facilitating business •fco^smcti«nis>- not that of 
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devising appropriate pricing policies, except to note that 
prices should be based on sesssces seaningfal to the user 
of a service. It is iaportant to p«rait conventional baring 
and selling to he extended to the ear ketplace. There is 
another necessary aspect to these -traassetloiie — the 
settlesent of disputes. In ty#iea-l: coepoter sv steam :, tt§ere 
say be saay parties to a dispute, the installation 
aanageaent, the prograaaers, and the user of the systea. In 
a ' aarJcet place, each veadatci-caai' sake use jtb# .aany " other 
ser rices. Onle&* gatld elinea -a re ^siafeafel Ishod '-.-for assigning 
responsibility ehen service is not satisfactory, the aarfcret 
bee ones unattractive to the user who does not s«3oy the 
details of liUgat ions. 

To deacjtstrate the feasibility of the >- ; «oa^ute« as a 
aarket place for services, an ispleeentation will be 
described. Baltics, a systes developed cooperatively by HIT 
and Honey veM, will be used as the basis for such a sys&ss* 
aultice is appropriate because it m designed to serve as 
a basis for a coaputar utility. The ieplenentation of the 
aarket place will serve to de a on strata techniques that can 
be applied to other conputer systensi. The principle 
extensions to lultlcs will be the creation an eavlroaneat 
for services as opposed to progress including a financial 

« 

systea for conducting business inn the aarketplace. 
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Once the framework of the marketplace has been applied 
to a single computer system, it can be extended to a 
distributed computer system such as the ARPA Network. By 
applying the framework of the marketplace to the ARPA 
network, some of the practical problems encountered in 
trying to offer services via the network can be resolved. 
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CHAPTER TWO 
SERVICES IS A COUPLER BPfTROOTEirT 

The goals of a computer system as a*n eiaviron-ment for 
services and those of structttrtfd ^ofriliBio^ have much in 
common in that they both represent attempts -to control the 
complexity of computer system* by* =*ecoi»^lifeng i the* services 
or modules of the system. Each module is viewed in terms of 
its interfaces with other p^og^aws^ ^ ^In ^ana^y#i«g one 
program the internal operation &£■■<&& -fdnd&vidtot*! programs 
it calls upon is net import***^ >4tedm> prcpgiai module is 
considered to be fully responsible for the service it 
performs. Thought one module may; maJke msec* lother services, 
the user of the module is iai*»la*#a from these secondary 
services. While -this approach h*s bee* taken in some l*rge 
programming prelects, the facilities «#g«ired for properly 
protecting programs "from , unwamted '^afteraction are 
inadegoate in most computer systems. 



The computer marketplace and structured programming 
share the basic goal of mafcfcng sore efiectiw use/ of the 
computer system. The desire *ox «od»ia^ty stems from a 
need to debug a large program by analysis of local 
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relationships between programs. For the marketplace, 
nodularity leans that each vendor takes responsibility for 
his service thereby relieving the o^er of concerns about 
the details of the operation of the service. The ability to 
assign responsibility ia important in localising begs in 
programs. One can determine whether a bag is in one' b own 
programs or not. if note, then itne bsgiis either . .1* another 
nodule used in ; ; n*h'icfc case, the person responsible *or Tthej 
module ea* be informed, or it is in the interface to the 
other module, in the aarketplace, th« clear assignment of 
re«pon«Lbil4*y im necessary for^ isolating ■■, deficiencies cia 
services and for resolution of disputes. 



^ i J.,!"" 5. 



If *he computer is to servem#ca basis for providing 
services, an adequate fxaaevork east be developed forth* 
financial transact! ems a ssociatad with fttea buying and 
selling of services aaong the participants i* the 
marketplace, ttoce tee* -eimply r/ ( )tiM«t:^-) possible to 
transact business, the marketplace i meet make the sale and 
purchase of its services very convenient. The financial 
system is, effectively, a system of resource allocation 
simplified by the erne cf a common measure (money) for 
e*chftngingireeoerces. Onlike many systems £er accounting: 
for the use of computer resourceftr the financial eystem of 
the aarketplace is not eeaat eimftly as * means -of 

Chapter 2 page 1* : VH17* 



Services In a Computer Environment R. Frankston 

allocating costs of the computer hardware, it must permit 
the assignment of value to resources created by vendors and 
embodied in the services provided. 

The marketplace puts requirements on services other 
than those strictly dictated by JKtriictared programming. If 
services are to l>e sold to consumers (as opposed to 
specialists and 8<>phis1ftG*ted r ^sers) in, ^a competitive 
market, it is important tha* tfce services be attractive to 
users. In addition to the cfca«acCifce*asstAG» of specific 
services, general factors .camm contribute to the 
attractiveness of services. The include: 

" Convenience: »hat is required of \ the user to take 
advantage of th«; sertie»?>^i|t jttik the user know 
outs id* of his particular ttppli^satioa area? 

- Couple tettiesa: Must the user £ access multiple services to 
accomplish his goal? Cao he ?s©c«m;pli*b tfae goal through 
the «se of a ^saall fjHMibjeas-i -mf a MexmMcma >that can 
communicate in a common laagusee? -.-s s- - 

- Relevance: Cam the aset« *spwW nt^ itoe yai»rvic« ia terms 
meaningful to him, or must he>:l«a^§aq«om« special purpose 
language? Is the service interface oriented toward the 
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user • s prcblea or aust the user eake' the problem match 
the services available? 

- Safety: lhat risks mst the user take in order to use 
the service? Is the service so powerful that a ninor 
error can he catastrophic? Will ct he msec be able to 
predict the effect of his request T Does the "principle 
of least surprise" apply ■■••>** .&oe*«*he behavior i©f the 
service confers to that which r^th* om»E ;-r intuitively 
expects? Vhet assurances does the -casex have that the 
service vill be satisfactory? If ^tha service is 
unsatisfactory, what appeals .does tha user shave? 

The ale of creating an environment for coaputer 
services is to si nplify the offering of services. Sose of 
the techniques have bee* sen tioned above* : The ; oriaary 
technique is the decoupling of services by requiring that 
'the vendor of a ■w&£9to6m"yto&3*nmfkmf&t<&9mtmmtiM&^ for 
his service at the interface to €t»osjectiica.: This is a 
prerequisite for the criteria listed above. The service is 
convenient if the user need not be aware of the details of 
implementing the service. By taking full responsibility for 
his services the vendor gives the user a veil defined aeans 
of finding who to appeal to when any aspect of the service 
is unsatisfactory. The degree to which a user or vendor can 
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be liable in such a situation can. he limited by contractual 
arrangement between the user and the vendor prior to 
accessing the service. 

The financial sy stent of tbe marketplace also supports 
these marketplace criteria and is discussed in the next 
chapter. The problems of developing standards and design 
criteria for service is a much lacoadJBfet^ofcle* than the 
design of the environment for services and is beyond the 
scope of this tmesis. 

The availability of many services,., possibly in 
competition, is necessary to provide a "critical mass 11 of 
service wherein one is likely tofdtnd a, service appropriate 
for a particular task cr Mone cam ^find* a set of services 
suitable* for the t ask « Services must also be available to 
be combined for the creation of more powerful services. The 
coapetition between services in the marketplace is a 
primary motivation for making seEvicee as a^tracMve as 
possible. To provide an envirojMwaib i* whsicb ^aAl jSjesijrzces 
can be made available to the consumer ;<*»? a uniform manner, 
it is necessary that the users and services share a common 
pcol of resources. This can be done, by sharing a. single 
computer system or by establishing protocols for 
communicating between services, within a distributed 
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ccapater systea. In this latter case, the sarketplace still 
appears to the trser as a single shared cosputer system. 

Since con pe ting services are sharing a coaaon cospoter 
systea, it is necessary ttat they Can tet aasttrefl that no 
service can interfere sit* any other service either 
■alicionsly cr accidently. Interference can occnr vhan a 
database is altered, when a pro^ra* is «twi*a, or even vhen 
service is unavailable because one aser is exhausting the 
capacity of the systea. The elininarti4>a of unwanted 
interfaces anst not prevent noraal interactions between 
asers and services. Both ith« >ven^ors. Sjnd ithe wsers shoald 
be able to control these interactions so that the vendor 
can selectively de ny acce sm t» bisf senice ^ so that the 
user can prevent the vendor having anairthorized access to 
"the nser «s data o»-is©new ;: a«d>i i 4so*«s.ila*,^o*wctT'^ie5;iaciiv«cf 
of the subscribers. 



The cosputer systea as >a sarketplace differs fros the 
coapoter r systeit as a prog^naing enviroewsvtw Tot a "nser not 
doing his own programing the systea eJawsfe provide an 
interface to its services. The purpose of this interface, 
which is sieilar tot conventions! coses nd processors, is to 
siaplify the accessing of services sad to perait business 
transactions associated with these services to be aade 
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conveniently. Conceptually the user can be viewed as 
accessing the services from a typewriter-like terminal, 
though specialized terminals and interfaces are also 
possible. It is not, however, reasonable for each service 
to have its own unique mode of access because the user 
would be required to learn the idiosyncraci.es of accessing 
each service. Thus the computer installation must provide a 
uniform access interface to services. The user of a service 
can also be another service so that the interfacing 
protocol must also be suitable for use by a program without 
human intervention. 
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CHAPTER THBEE 
THE FIHANCIAL SYSTEM 

As explained in the introduction, a viable financial 
systei is key to the successful operation of the 
Marketplace. The purpose of the financial systen is to 
pernit standard business practices, t© operate within the 
fraaework of the Marketplace. This differs froa the goal of 
Many existing conputer resource accounting systens as the 
eaphasis is en the transactions between the subscribers to 
the conputer systen as opposed to recovering the costs of 
the coeputer systen. 

The priuary reguirenent for the financial systen is 
that users have confidence in it. Confidence requires not 
only that the systen be secure and trustworthy, bet also 
that the systen be convenient and sinple enough to use so 
that the user can be at ease with the systen and not worry 
about being at the nercy of a systen that he dots not 
understand. The degree to which the user can trust the 
financial systen depends, in part, on pernitting the user 
to apply his existing experience with the conventional 
financial systen to the new environaent as well as on the 
correctness cf the algorithms used and the integrity of the 

Chapter 3 Page 23 1/^9/7* 



The Financial System R. Prankston 

computational aethods used within the financial system and 
within the services offered. 

It is inevitable that disputes will arise between the 
users and vendors of services, unless disputes are resolved 
fairly, the participants do not hate any recourse within 
the marketplace in the case of unsatisfactory service . f f 
one aust pay fe* a service evea »ie«- it- has not been 
provided satisfactorily, the risks ' involved in using 
services ma outweigh they potential benefits. Central to 
the resolution of disputes is the determination of who the 
responsible parties are, for if responsibility cannot be 
assigned no action can be taken to resetter f a dts^utev for 
the vendor, the recourse in a dispute say be to deny 
further access to his service. The user lay apply financial 
leverage and deny payment antil the issues are resolved. 
The financial system must be able to protect the user «s 
right- to withhold the payments^ fer-s#ivicies* lb othfer 
words, the financial system is a servant- of the 
participants; payments are not nade and services are not 
provided without -this authorisation by the interested 
parties. 

In day-to-day business transactions a number of 
conventions hare been established to facilitate common 
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occurances such as the buying and selling of mechandise and 
to protect the interests of "* participants. When the 
marketplace for service is within a computer system the 
methods for financial transactions differ -from conventional 
methods because the transactions : :? do not involve physical 
assets or produce written records* It -ifay be argued that 
One can continue to apply current practices of using 
written notes even though tie ^ c S4S*vices #re within the 
computer system. This 'is analogous to i#e*#fving r a separate 
bill for each ! telephone call one iafcesi 1 The burden of 
handling the bills for many small tra£#&eti#fif£ would exceed 
the advantages of such €angibf# records* ^In ^factj in 
conventional transactions, the problem of processing many 
paper transactions is leading to tl the 3 development of 
electronic fund transfer systems. '<-% 

The advantages of a financial s^ten-desigried for the 
marketplace isthat it cin ^greitly stmpliff theybuying and 
selling of services. In designing such a system one iust 
provide counterparts to traditional financial safeguards 
such as giving the subscriber control over his own -assets 
(i.e. no payment* without subscriber's permission) and 
adeguate records to give the subscriber tae* ; J e%*Ivat.*ht-< of 
such conventional records r as t receipts, -ehseek^^stubsi and 
itemized bills. Above all, of course, the financial system 
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The Financial System R. Frankston 

In the market place's financial system, one pays for a 
service by transferring money from the wser*S account with 
the installation to the vendor*s account. This transfer is 
really authorization to the; installation manager to 
consider money fotmeirly *eing held on behalf of One user to 
thereafter belong to another user. 4 record of the 
t ran sa c t i on is k ept by the fin a»ciai SysiSem 1 aifd function s 
as a receipt, k bill can be considered *he converse of a 
payment in that it is a request made by 'a %endor f or a 
transfer of money f rom 'the ^s#r*s account Hoi "tne vendoir's 
account. For simplicity, we define a s&andard transaction 
as consisting of a bill and it associated payment. In 
practice, the bill may not be paid, or there may not be an 
explicit bill associated witfc the payment. 

lis pointed out above, %¥e burden ^-^o^^roc^slttg* the 
bills from many services can 1aFe^guit% heavy." It is 
therefore necessary to minimize manual *p*ooelsslng ; of the 
transactions. Host transactions are faSMqp staWlafed/ and- can 
be dealt with in a predictaJilev" of ^a%tbmati^ «ann»r. It is 
only in the exceptional cases that intervention is 
necessary. Thus one must be able to specify WhaPt action is 
to be taken in the normal cases and what conditions are to 
be considered exceptional aiid %heret*y require human 
attention. Simple examples of automatic decisions are 
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default ii »its for spending and aotWcia^ti^oft ,to ^>ay a bill 
when it becoies due. 

If the specification of^howto.; to- process each 
transaction 4s itsolf too coapUcated. f *he advantages of 
automatic processing of transaction* is ^oe* . She basic 
intesf ace to the f^aacieA s^Bteaj flhoaOd pernit a simple 
specification of which t^se^ojwji ,; caojaise., annual 
prooessi*o^ n The user has the potential c£ prog raaaing his 
ow* acre * sophisticated screening, c£ the fM^BPactionj^ .-tat 
the, specif icatiooe <f or pay neat a a*«ooi*ted wi4*< $ho 
standard transactions shoal d ft* sufficient for aost users. 

A standard transaction record wee daacr ilred abore as 
consisting of a request for pay Bent (or a bill) and the 
ccrree*OJ|a^cajBK^ ^hese. two ctjtmm. the 

transactica, record contain* a specification ^ of, c^cpdit^otts 
under wMpb^-mp*** M to be antoaatically ^dc. * sisip£e 
specif iont*Q«i *n<$u£ojs .the «&&wma£l**tim which payaejnt 
is = to be aade and -there aaxiaoar eAoe*t c of; mm*#tt«yjffk& 
aaount is normally the *rice tfte> vendor quotes when the 
users accesses a sec wice.^e *«*>** can thas request , a 
service andnot bw to -MmaXimaMi&m M^ki ifkd&wddually 
unless it : exceeds hiis '-UjAmc&A q4tim service is not 
satisfactory, he has umtdl the payee^st date-he specified to 
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cancel payment. 

Grouping transactions together into accounts provides 
the ability to consider classes of transactions. Rather 
than considering all payments t& »e F iMe from one large 
account that -the subscriber has -wfttiPtae installation, 
smaller accounts for specific purposes can In* mMihtalifted. 
This has the advantage of permitting limits to be placed on 
each of the accounts ^ so th*t an effof illltirit thretten the 
user's total balance, associated with^ «a^h account are 
default values for transactions and total limits for the 
account. Here importantly, the r user «c*i delegate authority 
for managing an account. 1 user ca*n petfmif "t 1 trusted vendor 
access to an account to collect periodic payments. He can, 
however, still limit the total amount that the vendors with 
access to the account can withdraw. : ' : f#f ? eiurse> this is 
against a background of contractual arrangements which say 
give the user legal ^rights td still iegliiiiisipiyients if 
the vendor has not satisfied the conditions of the 
contract) . Another advantage of having multiple accounts is 
the structuring of the user's records so that he say more 
easily evaluate his financial position. 

The specification of who can Is t what* with a user's 
account must be formalised so- that the afse>£ can delegate 
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sowe of the responsibility foe Managing the account without 
giving up full control. The ability to linit the aaount of 
responsibility delegated to another subscriber simplifies 
the user's task of monitoring the use of his accounts. Be 
can define five roles which a %u>s.criber ^caau^ave with 
respect to an account* ffce ffbjf^r^b^r , s.. !; ;iacq«s» to an 
account depends on the roles he is permitted to play. . 

Owner lay specify a - subscriber's -,. ; ,ate#ess to. the 
account. ... A 

Clerk lay examine the status of an account by 
listing the balance and any transactions 

associated with the account. ■ 

Paynaster lay authorize payments fi-on- the. account. 

Receiver ,, Bay acce pt _. j»y§eats ? to r> the_flf«jeunt» i ; 

Requestor - lay .. -pake . - r agues ts B f or v f>nayn)«;nts < f roa .. ; the 
account*. 
Roles aust also be defined with respect to transactions 
within accounts, k subscriber aay be given the ability to 
change the a »oi*nt requested (i.e. specify -flif .aaonnt ,,of the 
bill), cancel the bill* authorise pa meat {assuaing one has 
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appropriate access to the account with which the 
transaction is associated) , or to si»ply examine the status 
of the transaction. 

The systei of accounts, transaction records and 
controlled access peraits the user to simplify his own 
processing of his financial transactions by being able to 
delegate soae responsibility for their «anage«ent while 
still Maintaining overall control. For exaaple, even when a 
user delegates authority to Make payaent on his behalf, he 
can liwit the total aaount that can be spent by simply 
limiting the balance in the account to which he is giving 
access. Typically he nay give access to accountants or 
others providing financial Management services. 
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CHAPTER FOUR 
AM IHPLEHEHTATIOS OF THE HA3KBTP&ACE 

An important criterion in the design of the 
marketplace is feasibility. To demonstrate the feasibility 
of the requirements of the computer services and the 
framework fcr the marketplace an implementation will be 
presented. A detailed implementation reftaires that points 
be clar if ie d t hat are vague in the general Rescript i on , 
such as the exact method of requesting a.? servi-cas. ancL the 
exact capabilities of the financial system. The Hultics 
system developed cooperatively by the Massachusetts 
Institute of Technology {Project HAC) and Honeywell 
Information Systems will serte »# tlesbftsis for the 
implementaticB. See Appendix A for a description of 
Hultics. , «^ -'.7 ■. ,- • .,..-.:-■.- 

Hultics was designed tou serve as ^ the basis; for a 
computer utility and thasi ce»««b * closer to-, meeting the 
requirements of the marketplace t^MMa>i Octree systems 
generally available. Hultics can be extended without great 
modification to serve as the .basis., £or*£he marketplace. 
There are other systems that could also serve as basis for 
a utility. These include Btfs Wl7fca*ih $S^ys2~2/TSO 
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systems and BBR's Tenex system. 

In specifying an iaplenentatioo on« must first find 
representations for the elements of the model. 
Specifically, what are the representations for the 
installation manager, the subscribers, services and the 
financial system? 

The installation manager takes on the responsibilities 
of the Baltics system adainistrator. The subscribers are 
registered Hnltics msers. 

services on Baltics /•■■ 



I service is essentially any sellable commodity on the 
com pater system. One may sAnply sell access to a date base 
by subscription and then provide the service by giving tb* 
user access to the data, lore interesting are services 
which actively per for a a function ajtd mast be represented 
as a prograa fer the coapater. The regeirements on services 
inclwde the following: 

- One mast always be able to determine responsibility. 
There most be no nn advertised stdee *€f sets* Snch side 
effects are typically the ra>fca&an*f sharing t ©coo tees 
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without clear assignment of responsibility. 

- The subscribers aust be protected froa each other so 
that one would not normally be affected by the other's 
mistakes or attempts at penetration. 

- The user should consider the service to be v black box" 
and just view it as something that takes requests and 
returns results. 

- The representation should not prevent a service froa 
using other services. 

- TUie vendors of services , should be able to control 

access to their services* . •-- : --:.~^. ; 

- Services should be able to operate asynchronously. 

In Bultics, these requirements can be net _ by running 
each subscriber's prograis ia separate processes. Each 
process is identified with the subscriber's principal 
identifier (or access name). Thus th^e identity of the 
subscriber ^running a given prog ra» t -cj^i b#,^nj|^rninejL»at all 
tines. 
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Conventions must be established for eeaaunicating with 
services. Since, ideally a service can be viewed as simply 
taking requests and returning a result, we can associate 
with each service a gueue of regwestss ; • For each* queue there 
is (at least) one process that reads the regaests and 
performs the service. The details of the iapleaentation of 
services as processes associated Vith gains* is described 
in sore detail in Appendix b. - 

Process creation and coaauaication between processes 
via gueues is not very expensive in flultics, costing 
approxiaately a second of processing tiae for each process 
created. For sany services, however, this expense is too 
high. Instead of requiring it* v ««ir^roc%s«H --a service say 
be a subprocedure in the user*s "^iJi^si^Tlfcer* 3 * are- a number 
of drawbacks to this approach: 

- Since the procedure is being ran in the user's 
process, it is dif ficul* 3 - to^ determine who has 
responsibility for usage of *4^io«rce«'.- 

- Since the service and the ~user*8 r pro%raa& share a, 
- troaabar ' aeafory' ■ ^faore ; $wecis*&y£ -^ : tt- ; j ' eowtaofep - address 

space), they can easily coaaunicate via shared 
storage. This use of side effects can obscure the 
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interface and th as make it. -difficult to deteraine 
whether aasatlsfactory^ •ecvice-.wpaf tee fault of the 
vendor 

- The user last be willing to <ac9B»t t^e »en#or«s progxan 
since it till tan a&tfe tern: saaanv access a* the user 
hiaself and-' a*y tlms' -■ peMaam mdtimSm^e, in the <■. aser's 
nane and witaout his agr ue—nt or knea&aAfte. £his: is 

-■fcfteft* ieftofced^ttfaflB '4sb* «is»i«a apsca«P4^D0B^aiK^: i - -.a-i!:.. ;■ 

.•■:'. . ■, ;• '.. -i "■ .. .'"..„. J W - ; : . :" •■ *'■' Ti-.r-i i.;_. 5 ax BM^s j-* f s. fit? "; ^r«:--i n q -■ .. ■; 

v .-; w^*^*^ ^W -' vAWtf- naif 1 a©c**iP ai&*afeataatx.vtia« wusdaoeffiB 
progran : %e dan - ea^ly^3n*l^%--ieaisp& <*>*ta« * prosaa* 
renewing the clills^^ ^ttw-^lf ^^ itw cawoifl 

bein^ Charged ^fbie ^a*»r '4*a* eiaan Jar-^atapknagcao^ Ar-iaiaxng 
only the nodified copy. 

There are sone partial aolntions to the problens 
raised by attempting ^to ^rana* a»«^a»«46pxe^pa« Within a 
User*s process. '«»*sp*e1tt»»^aUsitf*I*«# «*# ajc^rwai ahich 
may b«-laitip4£«* tith 'Mi be redueee bj®»*lfl*ag tate services 

; of -t : he'-#-#ogrit»oft''*a i 'SttSa«*ipt**n »«sl»&*i*heisstlta)Bn©karg4ng 
for etfch iaiNJeatioa . - >--^- r '**- 

The use of the EingsiJOf pa«t«otteiiBa«Baitaaene^pafty 
to ran -the- other ^- pasty' i^awfeaasjaia ^a-de restricted 
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environment and thus renove the . problem of mistrust in one 
direction. For example, if the vend>«4» sec vice is provided 
as an inner ring procedure, the user nay not circumvent the 
vendor»s protection, bat the vendor may still misuse the 
user* s access privileges^ Since it is? vefy difficult to 
provide more than one inner ring procedure is a given 
process, this aechanism is of only iif^ted' mtilitf » Jn his 
doctoral thesis, ,-. Sckroeder >tmwm>o& i ■ mechaf*|#m for 
general ixing rings :tfco- permit the mem ©fb - «fi^Mplm> eutua lly 
suspicious subsystems in a given process. While Schroeder's 
domains provide- a viable means ■■ :ofe ; #roj^im^ jBom^'^Be^-vices, 
they have not been implemented ; and *ilt& tMre^pe not be 
explored fscther in the description of the implementation 
within the context of the mfa&im4tltk&im&&Kb0^k.j'<. 

The Financial System on Baltics 

the financial system is a speoiai .tseivice in that it 
is offered by the installation ma»a«eme«t j^d-is- used by 
nearly aM services and -,. thus 3 »m»t b« efficients The 
representation chosen is an ? -4 t«MS ring (t* :x ntliv%leged) 
procedure available in all processes. In tultics there are 
eight rings. The innermost are reserved for use by the 
system and installation and cangpeti 'therefore, r„he : used in 
all processes even those that are already using nultiple 
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rings. The use of an inner ring has the virtue of being 
simple and efficient. It also provides a secure financial 
system though it doesn't protect that subscriber against 
errors in programs in the financial ;■ mj&tvm, ^ a protection 
that is superfluous since, in general, one cannot protect 
against the installation management. Appendix C gives 
sample sections of the Hultics Programmers' Manual 
Accounting System Supplement and- cam b«r "referred to for 
more detailed description of the interfaces referred to 
below. 

The entry points for programs calling the financial 
system can be divided into three main groups according to 
whether they deal primarily witfa accounts^ transactions or 
services. For accounts, the operations :xjo»i3i35t of creation, 
examination, modification of access and termination. For 
transactions the operations are: tfrea^feKEr** authorization, 
payment processing and reguesting, examination and 
assignment to a service reguest* Service iJ#gu«arts pass -the 
specified parameters to the service. Saekc* reguest might 
also specify a transaction which /the aaescice may use for 
its bill. The transaction specifies an amount authorized 
for payment so that the payment can be ma&e immediately if 
the vendors price is within the authorization range. 
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Accounts aire collections of data representing a set of 
balances and relationships with other accounts. Associated 
with an account is a set of jk?cjB#s privileges. The 
following iteas are aaintainsd for each account: 

\) balance This ism set iX&. pj^c^JC^ ww»nt# anft jowits 

representing the balance on deposit with the 
. installation aanager- -., .? ■■■ 

2) payables This is a list of transactions representing 

payaents froa this account to another 
account . The i .,sey be pending or processed . 

3) recei Tables This is a list of transactions representing 

payment ?, - *& •; <*fcds> r ■.■ account o af near . aea*|tJ*er:; 
account. The transactions say be pending or 
processed. 

4) access list This is a list of subscribers nsuts and the 

that each ha a to the a_cco»nt , The 

say. bet -■. * >-, ■-.- 1 _> .;.-. t > ,.- . .- r. a j » r 



owner The owner nay set other!s,< access to the 

.account*. . :,?.< * '.■- _ ?.. " 

payaaster The payaaster aay authorize payaents froa 
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the account and change existing 
authorizations if pay sent has not yet been 
made. 

reguestcr A user vho has access to request payment aay 
create transactions to transfer amounts from 
this account to another account to which he 
has receiver access. 

receiver Access to transfer payment to this account. 

clerk A clerk may list the status of an account. 



A copy of each transaction record is kept with both the 
account to which and the account tfro» which pay sent is to 
be made. It can be retrieved by using the name of either 
of these aecowfttsr and its unique identifier. The 
transaction record consists of a bill and its associated 
payment. 

When creating a transaction, one specifies a vendor's 
account r j a .-. user's account ---acnfe tar ~ intelligible: .■? (i.efi 
Enlglish) description of the transaction . The vendor aay 
then specify the amount of the payment he is requesting. He 
may change his amount so long as <the transaction is open- 
He freezes the requested amount when he closes the 
transaction. Thm w&m: speeifAesst *h« amount to be paid to 
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requested, the a count authorized and 
the re aaining balance in the account 
for the given units. Payaent will only 
be sade if the transaction is closed. 
If the account is open on the specified 
date, the transfer will be aide when it 
is closed. Otoe this ved a t»j.i®t passed, 
the authorization amount cannot be 
decreased because the aoney has already 
been •trsxstfm&cedn* --^. ■ill? ,.,'-■ 



6) aaount paid 



The aaowst paid iof «rU< 3?fils ^presents 
payaent which has tmwdtiOBmtst erred. 



7) description 



An intelligible description of the 
purpose of the transaction. 



8 ) whet her o pen 



A status flag. A 5 * long us the account 
is open, ? -the r. aaount s * of ^payment 

requested .rattyot;* xaoidiMedU;- > 1 -■ - 



9) access 



The nane of the subscriber who aay 
change the aao/unt of payaent requested. 
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The low level entries into the financial system 
include entries to create accounts, create transactions, 
specify access, specify quantities for payments and 
requests, and reading the contents of transactions and 
accounts. These are described in appendix C. appendix c 
also includes the entries used to request services since 
the financial system -.^c&s as the intermediary between 
services. :■-. ■ 

It isn't sufficient to specif y the interfaces to the 
financial system, one must also be able to sake effective 
use of :,-tbe»* 1km aim **& tfc»,,j financial system 4» to .d«.«et», 
than permit transfers of money between- users. It is also a 
means of providing the subscribers to the marketplace with 
control over their financial dealings, in an. envizowteirt 
vh ere ther e are /Jtsaf :. transactions a hedng ma de , e f f ect i ve 
control Beans not only that the subscriber be able to 
decide the fate of each transaction,. 4but aiaootbw* .- he is 
not swamped with data ils that , would mender hia unable to 
deal effectively wdth important transactions. Soae examples 
of siaple transactions: 

ease one: a user ;.p»rchwses vm service and pays in 
advance. This is sinilar to a conventional cash purchase 
except that a record is nade of the transaction. The user 
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asks the financial system to make m payment to the vendor»s 
account. The user then sends %he ^r^ice request to the 
vendor along with the identifier of^%^ trfcrisacti.cn. 

Case two: a user purchases a service $mt does not pay 
immediately/ The u-seriwt 'sii^^atss parameters to the 
service an* the service will in *«i*n «l*e a reguest *6r 
payment to the SM^s arcouintV^ri : '~<St3»»r to tcf^so, the usei* 
must give the vendor access- te make - pityteri^ requests and 
then afust consider the reguest to decide whether to make 
the payment. A simpler procedure is " for tne 1 user to create 
a transaction arid then give^ 'tfceP venilor 1 access only to° ■tfce* 
particular transaction. If the aselP 1 expect 2 *the lc Service to 
be satisfactory, he may specify a maximum payment for the 
transaction and a date on which the payment is to be 
automatically made'.-' '■ Tnn«y ^ unless 8 -^tne 8 service is 
unsatisfactory or the bill is higher than expected, the 
user need not be bothered- w£tt~ IteMdlrig 11 ori 3 ^y%eut for the 
transaction. .>:.-.-.' '-:-■' 



case three: A user wishes 3, td 4 pay a grottr of vendors 
automatically but limit the ti^al^fcymeati This is useful 
in paying utility bills such as gas and electricity. The 
user can create an account for tn is purpose arid give it a 
balance egu ivalerit to the ma xliwir allowable » payments^ He 
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can then give the appropriate mndaXjS .access,, to, Bake 
payaents to themselves and does f , not -:.seed to check 
transactions individually* 

To aahe bos t eftective use of tfae aaxkftplace, higher 
level routines than the? interface specified J^ the;; appendix 
would, be. s .necessary. These ; , interfaces #oald, tafce caxe,;. ,. of 
■4HI of the details aissocia ted •^^stasds^d transactions. 
For exanfle, instead -of, ; ex nO|.ci^^ ; r ,e^e£|Jpd,B4<.sr d#t# f#f 
each transactions, the rootines se»4#j 99 B9 B&&3 sses^y . a 
default date such, as the ;; end: «f :JO trbe~mss*»* a i^»*^ billing,?- 
period* Pr ot ocols f or , sore con plicated^ f^ aaaesjtn tav, sach es £ 
the use of crsd£t~ f roa a ■ third , «artar^ffn*t ^«|#oT ; -,he. : 
develooed ....... . . v . s _ r ... v ; , ? - .-> ^. ~ . ^ .. '- r 

M ;i -. ,~. Baltics, jfcSj a,, service- system. *i r,.. : . r .-, --.^.v, 

,, The s£amdaxd-,,., user^&i^rf^^ 
processor that is used to invoke progress. To tenser of 
the marketplace this is unsuitable and a sore service 
oriented . intex|a£e 6 ^ neces sexy. - -Ja^ as ing the ..service 
interface, the user ms*df, v only 3d spacer tb«d service*, he, 
wishes . to. see and the:. t parmsetepf- for jr?thej secf ice>- ■.•|*is- 
interface^also includes the ^ghsf^ lev e£ r , accounting aid* 
mentioned,., above. rjn* s pract^es ttbis^ats^fafSij s|£h£p^aJ.sOf, bet;' 
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used in conjunction with special consumer (as opposed to 
programmer) oriented terminals. 

To illustrate the characteristics of a consumer's 
interface to the marketplace, a script will be presented. 
The purpose of this script-is to pre**8tthe reader With an 
overview of the system as described so far; the example is 
not meant to demonstrate an ideal interface. For simplicity 
in presenting a script, a typ«m*i*«fc iike^terminal will be 
assumed for the scenario below. The scenario is very 
limited in that it does aot:i&ex#16r*^*fc« modesSOf user 
interaction that might make the i «*« of ^wriee imach more 
convenient, but isi meant as asrnell e*aap3l.e of *be ase of a 
service through the system. 



The user's typing is underlined and the computer 
system 1 » ou tpu t - i* " not underlined . i s£fc*m*niar y on the 

scenario f^lows^F/zn •-^-^ ** ■--'■' 



■ f'* *~ 



Welcome to the Scenario Marketplace 

Date and time: January 1, 19^jt^g«b a* ed± 

Default account: "Hisc Bills" 

,, •■_?. ':''-■■■-'■'■ ..'.,-.: i .,■.' •-• .La. :• •■ j -:•:..-' c-'rcn isrf? rrj; - ;-. 

// Host %Ca1aSactiows5 hav« iucki information in common 
which need not b% sp^teifiia*J%»piicitJLy each time. 

Default ^a^ment date: 2 month* (Rarch 1y>.*975) 

// The -dale on which payment >*&!& unormaiLly be made 
if «o farther actis<» «i« taJeeif^/Thte^Miount of the 
payment will be «e#tc*c**flr to? th**e#aalt limits. 
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Bequest: account snaaarv 

// This is a service * kick helps :*ajjas«e the user's 
accounts. 

Bills paid recently: 

// Aaount Service Description 

$50.00 lewsaagazine 1975 Subscription 

$18.97 Electric Co Moveable %9JM Service 

$2.34 Marketplace Service charge aoveBber 1974 

Bills maturing soon: 

// These are printed as reminders to the subscriber 
so that he ca» cancel payaent for those services 
that were unsatisfactory or are iucoeplete. 

$34.32 Reference Library January 3 1975 

$32*42 Geaeral *regranaing «aaneary 4, 1975 

Ho receivables overdue. - 

//To keep track of payaeo ts due to the subscriber 
in his role as a vendor. 

Request : r ead aai| 

Ho aail. 

// * typical use of the aarket place is coaaunication 

- • vita, other wmtoe&kH&*tc£*i*k**t99*t&*&(te>si&.:* 
service which is aaall enough so that the user is 
rarely concerned with BB*e>gA»tb the oPffjaents 
directly but instead sets a predefined Unit and 
does not request any notification at all of the 
transaction. 

Request: ypo4ffiBfEl«fr . 

** - x. i .;. t- •:■> < x i. ' : J a .m o o :> <> t S u - :< •.■■• ' 

// Shopping that does not reguire actual handling of 

.: goods ttiRBi. be- i: done via £**> es»fl Pj fr« c $ ya$ ea if it 

:±& ..itic&ma&iim&i ,, enough* j^P ftjyM-»^»HP*»P ie # so * e 

explicit interaction with the financial systea 

'.aust take ■ places sinceN-, ; j*hjaj ft 9apiopttJ^ £ ^of aoney 

involved exceed the user's default Units. For 

the purposes , ^of A&Uk].<9fi9VMCtoui&.3<mp beginning 

. -■:- - T»itb; F5% <*fcft cojwajaterdfao jt&atrifitLBJipa&l systea as 
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Do you wish to change your staakdard chopping list? yes 
change, add or delete? change 
item? nj}.k V liters 

// Reaember that the purpos* ofttshiasst scenarioi is not 
to deaonstrate an ideal interface, but just to 
deaonstrate hoir one wiffeft deal with services. 

warning: Default 4uth6ri*»jfc£»a ? L&si B3gtm00% 
Cost of iteas is: $3d.39 
Transactiohxi^ * g*oieerifeB3#f .^ftn 7 Si. 1 3 4" 

♦authorize gr oceries: 01. 01 . 7 3. 131 S3*. 39 

// Oser authorizes the increased amount. This does 

. not necessarily: " ai»tWKia«4*BMmtiatto s<|iiffMt • In 
fact, the user is able to change the aaount at 
any tiaejuatil the aotie^is actually transferred 
to the vendor's account, but chooses to specify 

-: the < a ao«at :> no* so £&a t > he. . *J41i ««tl- aefed to 
exaaine the transaction again. (The "*" is used 
in th* ^exej^l*>s*os«ean,-5ithi6fe> *h« BiCoMmaffldisis 
directed to the financial systea, rather than the 

Bequest: ^ v ? 



Since the financial systea is so central to the 
marketplace, it Bust be very reliable. It Bust also provide 
convenient facilities for subscribers to aonitor their own 
use of the aarket. In addition to the file systea integrity 
features of Hultics, records of transactions are kept in 
duplicate, one copy with the account froa which payaent is 
being made and one with the account receiving paynent. In 
each record is sufficient inforaation to locate the other 
copy of the transaction. Since the two copies are on 
opposite sides (i.e. credit and debit) of the account, the 
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total amount of any measure is coastaM is the s|«tei^ thus 
providing a checksum for the financial system. * journal 
can also be maintained of all event* effecting the 
financial system. This jearmal is important for updating 
accounts from earlier version iftjtiie.» rcaftenof cataetopic 
failure and for resolving disparities between transaction 
records in tvo accounts. 

The user is safeguarded iby *thpl JsvaAiabCiitsr-; of records 
of all his transactions. To be intelligible, they all 
contain description of tae txa*tim*ctl4anafe* Since all the 
transactions are online, t.he user ma^ easily use programs 
for this management process. {imm;amwmpi&, &&&•£#& summarize 
his payments by categories cr other criteria.^ Having all 
the records available is a nixed blessing since 
unauthorized disclosure can be a serious invasion of 
privacy. Hultics offers the technical means of protecting 
the records, but legal protections must also be provided 
for misuse of the records by the installation manager and 
by others who may have access to read them. 
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CH&PTER FIVE 
DISTRIBUTED SYSTBHS 

A network of computer systems linked via communication 
lines can be considered as a single distributed system* 
Lesser degrees of distribution are also possible* ranging 
from a multiprogramming systea where ^ the processing is 
distributed by the software over 1 a number of logical 
processes, to separate computer systems sharing storage 
facilities, to separate computet "systems* with autonomous 
administrators who cooperate through a snail set of well 
defined protocols, ^ So far we have considered only the first 
case, a single multiprogramming e , <and j r possibly 
multiprocessing} system that: is »i«wed i aSf a homogeneous 
environment for coifatex servieeSki v :;' s 

To the user re guesting a service^ it is not important 
where the prog nam for the* service is* beiagc tu»j as long as 
the interface to the service is? Sieiia^efined ami: the 
parameters can be passed witluout complications. Before 
considering the ramifications at. i extending the marketplace 
to a distributed system, we must firs* i eaca»ifce tj*e reasons 
for having a distributed systea. 
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To the consumer, it is inconvenient to use aultiple 
narkets. The computer systea can be coapared with the 
telephone systea. A telephone subscriber doesn«t purchase 
services directly froa each phone company. Instead he 
subscribes to one phone coapany which provides *hiB with 
access to the subscribers of the other phone companies- To 
the subscriber, the telephone systea appears to be one 
large network - without the coa plications of aaay 
interconnections and differing tariffs. Id the sane* sennet, 
the subscribers- local aarket can sane j.e«p. his entry into 
the larger systea of aarketplaces* r^ 

On like two subscribers of a telephone systea, the 
coaaanication bs-tveepua;-: asef-oBadray sead*r& &*h not restricted 
to- a single set^of::e«a.t«n*lonSArfIn^sat#itieaiits^fa^a»etei:s 
explicitly presented by th«^»se^ feo? tiBa««an«s* aafe resjilts 
explicitly returned as aessages, the two parties aay 
coabaaicate via shared: i tina»arceevtaB£a^Mbfci the? >a»co|te of the 
restricted protocol for a«e«s*ia§it.i sa«rica(«sv*©r exaaple* 
the user say present -data to *Jmc-«andaatt baja passa.bg a aeacry 
address to the vendor . > Ute? ftendltrB % would thaa aceessf the 
data directly in this shared memory. Ihile this any be a 
siaple opera tioa within •. tb* eoa£knmmitx£v* single cob pater 
systea, it is aore difficult- to .^aaetamftj ; '*hdsr bode --of 
coaaunication to a distributed systea. For the purposes of 
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discussion, we will restrict communication between the user 
and the vendor to an access -? protocol wherein the user 
passes messages to the vendor via a queue of requests for 
the vendor's service and the vendor replies by sending 
messages to the uaer via a similar queue used for replies. 
It should i>e noted that tire name o£'?a service may be passed 
as a message. v-^ >:,; .. > 

4s in a single system marketplace, financial services 
•ust be provided, ks icn^ as '; f«ne can ^provide a secure 
environment^ interfaces similar & to theses specified in 
chapter four Can be provided fee a common financial system. 
When there are autonomous administrators* the approach of 
having a single financial systei cannot be used since the 
participating installations are mutually suspicious, fhe 
relationships between the installations is analogous to 
that between services at a single installation. Each 
installation maintains an account representing; itsistatus 
with respect to each other: in st alia ties. , Periodically the 
installations must sake actual cashr payments to resolve 
imbalances." ..-- ■*-.■•;;;.;- 

Hhen a user authorizes payment to the vendor, he is 
telling his installation, tos author! re payment by the 
vendor 1 s installation to the vendors If tAe vendor's 
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installation lakes this payi«nt it is, 4M*ef#ect, trusting 
the aser's installation to sake rfche payment when the 
accounts are resolved. This requires that each pair of 
installations establish a credit r^let&ertshi p. The number 
of such relationships grows with the square of the nan ber 
of installations* rTEe ■ ; r«*ia*sjiiiuaic^ fiai©*;; »auy such 
relationships is cunbersoae. To reduce the naaber of 
relationships, an interaediary can be introduced as a 
clearinghouse for the transactions between irustallati ens. 
This clearinghouse is £v If ill ing si eilar: functions to the 
installation aanager at a centralized ^marketplace, vith its 
associated benefits. Just muittmh'lfsmmmmd^auB a ear ket place 
financial systen does not : preclude especial arranges en ts 
between vendors # use of the clearinghouse is volant ary, bat 
is a reguireneht for keeping dealings with other 
installations' manageable. -.-•>---**>■•* -i--„^?-.. 

The A PPA network is an; <iai|»l6 of a distributed 
coapnter systen. It is; r couponed of autoaonons eoapater 
systens linked together through a aessage -> Switched 
coaaunicaticn systen. The importance of the network is? in 
its atteapt to define protocols to per nit the cooperation 
anoag users of these diverse coapnter- systeas* These 
protocols have so far been aainly concerned with the ose of 
resources at one coapnter installation by users at another 
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installation. The network has been used by some subscribers 
to purchase services ^riofe-^xeatefe* inaalvllvfc&Dvsv.' 

In order for a user to access a resource on a computer 
systea he Bust first Bake arrangements to pay for the use 
of these resources beforehand* This require® that he either 
have an account with that computer distillation or that the 
installation provide a coaaon atccofcnt f^ct ^n^tvork users 
without charging each one individually- For aany users the 
difficulties of Baking special arrangeaents outweigh the 
advantages to be gained froa such sharing. It is also 
difficult for a service to Bake transparent use of the 
network, i.e. if a user calls upon a prograa at his local 
installation, the prograa cannot Bake use of a service at a 
remote installation without the user having Bade prior 
arrangeaents — the user cannot treat the service as a 
"black box" but Bust be aware of the services it invokes in 
turn. 

A financial protocol can be established to facilitate 
the use of and payment for resources at reaote 
installations. Bach installation on the network is, in 
effect, a aarketplace offering services to its subscribers. 
The financial protocol peraits financial systeas at two 
installations to reguest and authorize payments at the 
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other installation on behalf of* their subscribers. The 
protocol provides bath installations idutn capabilities 
equivalent to those provided to the subscribers within a 
single installations. The aessages passed between the 
installations correspond to the financial systea entries 
described in appendix c« The aocoirn* and service naaes 
would* of course^ be. e aep and ed to indnde? tke ridentif ication 
of the installations at which the naae is defined. 
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CHAPTEB SIX 
COHGLBSIOMS *ND COHItEllfS 

The aim of this thesis has been to explore soae of the 
difficulties that hare inhibited the growth of 
computer-based services and the converse problem of how to 
make the capabilities of computers available to users. The 
solution to the problem of making mere effective use of 
computers involves a combination of computer technology arid 
human engineering* The thesis ; thus -v-J addresses both 
requirements for a consumer oriented computer system and 
for the technology needed for its implementation. 

Supporting services .'-in wolves a nor 4* thai^ast writing 
computer programs to perform specific applications. The 
services must be provided within a context that permits the 
user of the services to be unencumbered by the complexities 
of computer systems without giving up the conveniences that 
he is accustomed to with more eo^tventiOnat^^ervices. It is 
important that he have confidence ia the services and in 
the marketplace. This confidence "depends on a user's 
ability to predict the effects of his actidas and on his 
ability to protect what he considers to be hie right* ot at 
least to limit his risks* ; 
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For the vendor, the aarketplace Bust provide an 
incentive for creating services. The aarketplace, by 
permitting the vendors to sell services for a profit, 
supplies soig of this incentive. Competition within the 
Marketplace helps ensure that, the services sold will be 
attractive to users. 

Disputes will inevitably arise and nast be easy to 
resolve in eoaaon cases. Fundaaental to this resolution is 
the assignment of responsibility. A vendor anst take 
complete responsibility for his service both to provide , a 
sinple (and thereby attractive) interface and tor five the 
user so ueone who can be held accountable for unsatisfactory 
service, even if the ultinate cause of the problen nay be a 
secondary vendor who supplies a abenbicflasortice :to the 
pri nary vendor* . --o---*; .■::i ; ^ ca - a-..- „..». c-. 

Basic to a freer; aark^t i** a trustworthy financial 
system* Unless the subscriber can have confidence in the 
financial systea, he cannot ^aake ^effewtiweoase of .- the 
■arketplace. is stated above, confidence requires 
predictability and safety. By building .upon the user's 
experience with conventional business transactions, the 
financial systea of the aarketplace; eis intended t to allow 
hia to have enough of an intuitive knowledge of r the 
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financial system so as to be able to predict the -effects' of 
his actions. To protect his rights, a user Bust be able to 
selectively deny payments to vendors as a way of protesting 
unsatisfactory service. Bat it ism** enough for it to be 
possible for the user to exercise control, it Bust also be 
easy to do sc. To prevent the user fwo* being swamped by a 
large nuaber of transactions^ t&e i£Mawd»l sy&te* provides 
capabilities that permit hi* *>%©^ *«*&•» tfep his financial 
aanageaent and restrict his attention -otaHy to the 
exceptional situations,. *t t 

The aarket place, as described in this thesis, is 
feasible to implement within present*-day technology. To 
deaonst rate this f easibilit y V s a tf * iasple»enta tion %*s- been 
described based on Honeywell *«^ %ul%l^N5 = syste*. While 
changes are required to the ^yste*, '*lie#B are relative ly 
ninor and do not affect the basic struo*^?€F Of »ul%icsi The 
changes need not even interfere with existing Methods of 
using the systen. The inpieaent a tion has been extended to a 
distributed systea since a ^^ l»«ge b^ke*p3*ce ~- would exceed 
the capabilities of a single ccaputer installation. 

The thesis has, by necessityy 3 been liirited to those 
topics immediately relevent to ^ ^hfeP implementation of the 
marketplace, flany of the^ topics* that were mentioned were 
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explored only to the degree necessary to establish that the 
difficulties they presented were suraountable, but the 
solutions were examined in only a^aowi^ory^ifasJiiojii The 
priae omission has been a full discussion of the interface 
to the consumer except where used' ? in exasples andr* where 
used to define basic requirements ,* ioc >\ the liow level 
interfaces. *he ojnisj8i.©jn has been; irn^eational because- our 
understanding of? uthe, relevant issues ha» been liaited by 
the currently available en#*roa*eidfe-f.?-^©r jfcoch r .seasvayce©* ; 
Given the environaent of the marketplace, research in the 
design of the services tkeeselves can be carried out. 

Other topics oait ted include the legal aspects of the 
marketplace, the detailed iapl«ae#»ta*i on of the financial 
system, and the limitations og r ^ 9 jSj»Bteab sw* a$ Fhaties as 
*/ basic for a- marketplace* The legjtl bastions faced in Hfche 
marketplace involve the problems oaf ■•.; .a^ej^gro^rning- -the 
market as a whole -«* should it be regulated, wb*t 
constraints are there on 'then 4M*)p3ilajMsDB* a sanageaent; and 
the problems of relationships between ;t users ■■:.---*?■. what 
contractual arrangements are appropriate, «wau^Ji*plicit or 
coaaon law obligations do the parties have? The financial 
systea must he ver# ; robust <i^e, v immune to cat ast op he) , 
-even, though 5 the envir ODaent * inn *hiph i% r jtsjbs, jm»i *ot> be 
very reliable. Hultics has been designed ^aj^n „*a^sieb-«f.or,.a 
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computer utility but suffers from some of the same errors 
of omission as this thesis. Por example, is the system 
sufficiently reliable; is the security system appropriate 
for the "real world" when the value ®£ breeching it is 
high? - -■_.., T.-; ;.■«-. . 

Beyond the detailed issues of the market place are the 
questions of the* implication of the marketplace as a 
microcosm of an economy and the relationship between the 
marketplace and society as a- whole, ihat^ are the effects of 
napping "existing^ institutions •■ .-ashmen* -isas ->i banks, credit 
bureaus, insurance, communications ^systems (including the 
post office) / wtc, into ««cowp»tef ^iy«tee**ls marketplace. 
Seme of the problems will be intrinsic to any marketplace, 
but others will arise from the nature of the computer 
system. For example, the consumer would not be constrained 
by geographic considerations in the selection of secfic««« 
He will also be able to tise the computer as -as. -intermediary 
between himself and the services he is asing. .He may, for 
example, have a program which gives his a personal record 
of each transaction with a given service. An important 
consequence of the low capital necessaEy to create a new 
service is the opening of the marketplace to hordes of 
small entrepreneurs, what are thesadwantageSfeOf ssach, aaflea 
market? What are the disadvantages? What regulations are 
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appropriate? 

The social effects -of sik* a: i«arJ«gbid*ce aj^^hard^to 
foresee at this tiae. He can onxLy speculate. It is possible 
that such a Marketplace can becoae a significant social 
factor since it provides a very good environaent for aany 
services especially those that !■■ -iumAtm »;ao«aaa4iiation 
between people vhe*e sroae intelligent :i$ pcoceSjS^jig is 
necessary. The current -usysteiB of /idxmkm,Kmm& -igredAt ^«ge*eie-s. 
is an exaeple. The Marketplace is , also suitable for 
services .that require :,«iaple* ebu* persona&i*ed ^proce^sing 
such as catalog shopping or librax-yserv^c«Sr,#oth of these 
also rely on the ability to ii e&0mmniiO9&e .with a, shared PS©!: 
of inforaation* The effects of lessening geographic and 
national restrictions on inforaation sharing east not be 
overlooked. This is an extension of the inforaation flow 
aade possible by telephones and: airplanes. Finally, what 
are the iiFlicatioas of globally avaialable technical 
expertise, as supplied by coaputer based services? 

The aacketplace aodei of the coaputer systea is an 
idea whose tiae has com. The costs of coaputer hardware 
are decreasing so that the necessary computational power is 
becoaing available. In fact, the/aaior icost-of goaputer 
hardware today is the overhead* of new research and support 
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personel. As more hardware is sold, this cost can be spread 
thinner. Software represents a large portion of the expense 
of a computer system and the expertise for developing 
computer services is a scarce resource. The marketplace 
framework eases the burden of development of computer 
services since it permits the development to be 
decentralized among individual entrepreneurs, although 
although the availability of the marketplace will not cause 
the problems of implementing service to disappear. 
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APPEMDIX A 
Description of Baltics 

Multics, as a systea, performs two Bain functions: it 
distributes computer resources aaong the users of the 
systea and it provides an environment for running prog r a as. 
The resources consist of the hardware and the software. The 
hardware is Bade up of processors^ BeBory, itss storage, 
coaaunications facilities and- ot-her peripherals. Hiniaal 
distinction is ' s iiade- between the ' asflAmma > :sofjfcwmr*r ana* the 
user software. The systea coasists oS: a privileged 
supervisor which supports the virtual ywmwmcj. - eavironaent 
and aanages resources, and a &«3i^p£igi$JywgeAi portion* 

The running programs are organise* into processes, A 
process is equivalent to a Job or a task in common 
operating systeas. It is defined by ~j^mmksut%MipL paint 
(i.e. a location counter) asd a sapping ef< nanes in the 
storage systea to add resses ia ;-•**«? iprotsmSses --; memory. ;' The: 
address itself consists of two ?pajfc*5*i a segae&ti number and 
an offset within the segaent* ^ avogaont is, -mar its name 
iaplies, a piece of aeaory and generally corresponds to a 
single prograa or a data file; Unities anlces no distinction 
between the two. Two processes referencing the Esafmel' segment: 

Appendix A Paget 65 1/13/7* 



/*;£5^*!£$^3?S&^:**^ 



^SfeB-v y ■**3!*&?!*:* i .i? 



A description of Multics R..- Franks-ton 

nay know the segnent • by different nunbers, bat will 
reference the saie data; if one process changes a word in 
the segnent, the other processes will be able to read the 
new value innediately. 

The storage sysrten corresponds totmet:. taeadsitiotial 
file systens. The important difference is that once a 
segnent in the storage sy«te» has been initiated ("opeaed") 
by a process (either explicitly or implicit* y* it bee ones 
part ofcthe directly addressable n*«orT of the process. The 
s*£rag« systssi consists ©£* assseat g & j a#d catalogs - * of 
segments called directories. ^.MwfCtomWfwmj^-BAmmsmktaiM,' 
other *ir«ctori»«E and tfc*s*he storage, any st#* J***** m *Eee 
structure with the leja^es b«ing directories mat s»gnent6. 

Segaents of ' aeaory forn the batfis for the controlled 
shaadotg o£ in€o>rsata.onv Back process h»s associated w&fcir it 
a 5 principal utde^tifier d (ofe access jldji ihate * &s>~ £or*e# jfecsh 
the usee's naie. Each segasjit r..hM,rt AILsjfecJPf ;• th*se> 
identifiers and what access each has &*. the *fceg*ent. Thss- 
mm nser isaiy * be designated «**- feawiitgt access* ©sfcft res* 5 a H 
segnent while another -mmf. al so* writ* data> into jfct . , 1 

Baltics extends the, concept i of atfperrisor and problea 
states- found In :S«ttirv:ro|aBa^iB^.saifJihesj**o.o« .«ndt*l<iMreJn 
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system of rings. There are currently eight rings in 
Multics. The lost privileged or i&neraost ring is ring 
zero. In designating access to a segment one nay specify 
the rings in which the access is available. If one, for 
example, designates a procedure rf *©, \m - readable in rings 
less then four, but only writable in ti^s less- than three, 
the user in ring three may then use* the segment normally as 
long as he is not modifying iti To modify it, he wast call 
a program in ring two or below* This ring =two- program may 
then cheek the user's reguest for v*114i*y %md| in effect, 
extend the hardware access control meehanlsa " l>-yf providing 
arbitrary mechanisms Via r: so€tt»reS : -Fori ''m&w&le^ mae&ms. to a 
data base may be via an inner ring procedure which will 
return aggregate values, but not permit an individual item 
to be examined, data item. The limitation of inner ring 
procedures is that, if they are mutually suspicious, not 
more than one can be used at a time in a single process. 

Multics administration consists of three levels: the 
system administration, the project adaninistration and 
users. The system administration is in charge of 
maintaining the system integrity, creating projects and 
registering users. The purpose of registering a user is to 
guarantee that his user name will be unigue throughout the 
system so that it aay be used as an identifier. 
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Registration, per se» does not give the user access to the 
coaputer systea. This is done feyt the p£©je$t, ; administrator. 
The project aduinistcat or caa desigeate ai ,Us$-x9f besets *ho 
■ay login using bis project's nape. The project 
adainistra tor i* responsible v fere j the res-earce. asage by 
those- on thia : 3 . project, ax He, iftf *l#jJ spfgrifyi individual 
spending liaits for his users. ^.fsepp •a^excerci^e control 
over access to their resources by specifying ? ifhiffh, users 
aay have *hat> > access to- the a. r j Fe-c #papp§.e, the , apcess 
control list associated «ith -,ft,;/sefB^1^f#ecifi#%-:«hich:: 
users .{est prcjectsj=.»jay 5 read*:^«rit#^>dwc -e^«Bd e ,the,iSeg«ent»-. 
The- access.* .aay- be.differenfc.foc-eajChg j*B«gn>? • 
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APPENDIX B 
Iapleaentation of Service Queues on Baltics, 

Chapter four presented a aodel of a service as a queue 
of requests and a server for th^e requests. Such a facility 
can be lapleaented with iiijiial cha%q*r to Bultics. The 
following three facilities provide ■■'<*'■ sufficient basis: 

1. Message segments. Beseage segments are queues 
aanaged by inne* ring systea procedures. The are 
iapleaented using segments? *iu --tHe^ istois&ge systea, 
but users aay only -acc«SBi the a through ^these systea 

prc^?«dWDes;i; OsepB>«ay b&*« XUUwst* mix add entries, to 
' a queued i tAmt , - F >«M£ 'irftt- del&£gp tlMfeP" o«n entries ; 
and to listv ; «fcid tVssmbss* deletfct ^w9^ss< entries. 
Associated^ with ' : each * -yeneter^r ni iap ?.;•-*«<*; secure 
idehtif ication uf- €b*s 'QdMc&tettKt *n# t&*e entry. 

2. Multiple processes. Baltics users aay currently 
hafve processes created otf ^HAHLr «i^a&W ifb us# this 

■^ ■• : 'faci-M-t^- tJ*e~-u#eM fetnda^'M£Ksol^ti»&:.' of j&tie) 

:~;- process 5 -to bie --creatwd * t05a^»cqrt>se*te# ;pr*fccess 

coordinator via a« ue«sag* .•: segment. She absentee 

coordinator schedules the iprtwsesst to be ^trreatejat a» 
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if it were a job on a batch processing systea. 
Process creations are deferred until the nuiber of 
processes created in this nanner is below the 
■axiaua allowable. To sake effective nse of 
services* it is necessary to ease the restriction 
on the number of processes that pay .; be created on 
behal of user*. This |»j#.ri-ct4.onr i JjBr present mainly 
to siaplify resource scheduling. 

3. Interprocess coasunicatioa. Interprocess 

- communication .permits coordination, of processes by 
eathiis^ processes to atuft sifMla tor wch other. 
Processes nay 90 blocked ii>eu .stop running) and 
wait ±0 be awakened h>y such m signal. *or eraa pie, 
a process t ■£■**»?. gc blocked , smi&Xmtv** * r « ad * 
message froe a gueue. bjmb another process puts a 
message: in the queue, it ow wakeap the .waiting 
■ process who .can- then read end process the message. 



By relaxing tea -. «mjjats&ct£^.<mjt:. the member of process 
that a user can create, and providing fetter tools for 
managing these processes (sucfc as the ability to kill a 
r ana way process) , processes caa be, cheated %«r necessary to 
perform services. & service c&a be reo^esteid by putting a 
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message in a queue, associated with the q^eue is at least 
one server process* Hfc<e© the -service s request *is put in the 
queue, a vakeup signal is sent to tke server associated 
with the queue. If the server is not processing any other 
requests at the tine*; it wottl#rnt»#»Trea^U andv begin to 
process the users request. If its^i® *«af, ^herrsegues* will 
be processed when the ; server ?i s? fi»4she4i owitfei tfce& request 
it is busy processinq. By combining message segments and 
interprocess wakeups into one facility, the entering of the 
reguest and the notification to the server is a single 
operation. 

After system initialization, there are no active 
servers associated with a queue. Thus, if there are any 
pending requests, or when the first request is entered, a 
process must be created to act as a server. The description 
of the process is associated with the queue and together 
they form the representation for a service in the Bultics 
storage system. Hore than one process can be associated 
with the queue so that the service may handle more than one 
request simultaneously. 

An example of a service in the current Unities system 
is the output daemon which takes requests for bulk printing 
and punching. There is one server process for each output 
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device. In the current implementation, these processes are 
created when the system is initialized, or must be created 
explicitly by a operator. It is not, however, necessary to 
create these processes before they are reguested. If there 
are not processes available to handle a request (and the 
maximum number of processes specified for the queue have 
not already been created) , a new process can be created. 
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APPEHDIX C 
Functional listing of entries* into the financial system. 

The financial systea is -,lSritl.^ibl«- tao all other 
services of the marketplace. 'S*imtir* it " ! i# 7 »6 central to the 
operation of the »arketpia«^?»iu^ '4l(^*iiui«i4Dfei for most 
transactions between service^ 5 i$MBt&4i? 9 i^M^«ration must 
be given to its implementation. For this reason, the systea 
is implemented as a '--s^t !* 1 inner ring procedures within 
Ifultics. To the programmer, this means that the financial 
system is accessed by using the staMftft^fljjft tics- subroutine 
call mechanism. *&nce the sysi^W i%*«tf^l4»n%S: ring, the 
user cannot ma k# ! unauthorized ret«r«oc'miP3£>£-Jt$n% financial 
system databases^ 5 _ajfstfoooj3_*si.l 

The interface^ ! ^o¥cWn*r^r points) of the financial 
system can be roughly divided into three categories: those 
that deal primarily with mixk&&^^*mm&*teS*fe#mq services, 
those which permit management of^lft^M»t^%j^%hose which 
are used to manage individual .&lntimmfec$lMlfe&"' J 

The entries for r equeWinV ™ *ie¥%13^eV ¥t« ts iincluded in 
this appendix because the financial c -l#fllfcejp* %fets as the 
interface between the services—" ' *'■■-• 3«a;>J. , sooi; ; 

iLppendix C ¥ag» ^3 
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Entry nane Page 

Services 

reqaest_ service ., 9a^ ; 

list_peiMlii»g_raniejB*s^ 90 

cancel_ser*ice_reg«est^ 7Jft^ 

. crea*e^5erwice.^pi«;iie W ' .-■ ,, |ly.,„- 

■■-■ • I- . ■ > ■ ■ : ■'■ ■■ ' :>,C . . 

■ • t ACHP&patS ... 

' . ;.- Cr-«|^e^C«|*|iMv.-;:; ..-:' = . --.v ■p R ■,.,^,... : ;•- 
*«t. |*CCa**_. - . • ■ ? -; »;;":: 

-listj_accottfrts_ •JM.-.-v- • 

Transactions 

, create_transactioii_ .. : _ ■ #2..,. 

set_atttkori*atioa_ . - . , 4R% . 

set^egae^^ajMORaat^ : ,,,.;. „ ,,9j5k : -, ViP . 

get_paj»eat_st.at»s_ 86 
get_^ransacti<m_stat4is wi ... - .., -. BQ - : 

Bake^pafaent_ 91 

clos^transaction_ ^g 
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assign_transaction_ 77 

specif y_receiving_account - 96 



R. Frankston 



Tables 

account_status 76 

f inancial_system_error_table_ 83 

transaction status 97 
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N aa g: account_status 

This is the prototype for the structure in which the 
status information for an account is returned. This 
inforaation can be retrieved using the entry: 

get_account_status_. 

For aat 

declare 1 account^status based, .- .,-.-,- 

2 version_nunber fixed binary, /* is 1 */ 

2 nuaber i;-of _m i»ble» fixed -**«*« j« :, r s 

2 Duaber_of_receiiables "fixed binary, 

2 lengt*_of _access_lisi f iied binary, 

2 balance fixed decimal (15, 2), 

2 payables 

(0 refer (nuaber. of payables) ) , 
3 transact ion_ id bit (72) 
2 receivables 

(0 refer (no»ber_of_receiTables) ) , 
3 transaction. id bit <?2) , 
2 access_list 

(0 refer <leagtfc_of_ access list)), 
3 subscriber_nane char (32) , 
3 access^flags aligned, 

* onner_access bit <t) , 

4 payaaster.access bit(1), 
4 requeat_access bit (1) , 
« recei*er_access bit{t) r 

* clerk_access bit(1); 
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Name: assign_transaction_ 

This entry is used to give a ---vendor access to set the 

requested payment amount in a transaction. It is called 

automatically by the reguest_service_ entry for the 
transaction id specified (if it is not zero). 



Sisae 



declare assign_transaction_ entry ( char(*) , fixed 
b i n ( 7 1 ) , char { *\ , fixed bin (3 5) ) ; 

call assign_transaction_ (ace ount_ name, 

transacti©ii_i5, assignee, status) it 



1) account_aaae 

2) transacticn_id 

3) assignee 

4) status 



The name of the account containing the 
transaction td be' assigned* (input) 

On i que identifi.ee' of transaction being 
assigned, {ittpnt) 

The name of the subscriber, or service 
to which the transact ion is being 
assigned, (input) 

standard Baltics status code, (outpatf 
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Wane : ciose_transaction_ , j..--. 

This entry is used to close an open transaction. 
Closing the transaction enables payueftfee-tiCfc :-bef,*«de and 
prevents farther Modification of the auouht of payuent 
being requested. .•*■•,. ■.. ■.^■■■■j i ;?vi.=- ■i > -.h-._.-- *^ ; •-■ 

Usage: /-,. ' r - ■* • 

declare close transaction (char(*), bit (72) , fixed 
bin (35)); 

O \\ ; -. ~-\ ;; 

call close_transaction_ (account_na«e, 

traaeietioa^id, stat*ejj 

;. ( ice) n. .'-d. psro it*'-"' ;•-?' ■■> 

1) account_nane The naae of the account in which the 

■ -.•<;:"" .■;. ^txanu^ptiojR c^ffctojb^giMt* iim**** ■ 

2) transact ion_id The unigue id of the transaction. 

(input) '; ^ 3; -. !? .■ ^ - ;S: . ».--v -. <r 

3) status Standard ty«t» status code. Is zero 

■if ; i*f« transaction is closed normally. 



it ■- 
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Name: create_account_ 

The create_account_ procedure creates a new account 
with owner's access to the specified user. The owner wouia 
then use additional financial routines to initialise? the 
account as desired. 



fisaas 



declare create account - s*s ebtx^r («*a#**r# char(*), 
char {*), fixed bin (35) ) ; 



call l^eat*-accM»»t_> (accoah*_*a»e , 
owner_naue, status) ; 



billing_account. 



1) account_na«e 



The naie for**tht& account assigned by 
the subscriber. This naue aust be 
unique *foc %**£ -accounts created fey-" the 
sttbeet&feet* " :>4tth%-- Hultics procedure 
unigue^chari^aqiitfj} be used to create 
unigue'~na«es~"if necessary) . (input) 



2) billing_account The account to which is to be billed 

~ for the service charges for the 

creation and aaintenance of this 
account, (input) 



3) owner_naae 



The identification of the subscriber 
who is to be given owner* s access 
initially, (input) 



4) status 



Status returned. It is zero if the 
account has been created normally, 
(output) 
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N ame : create_service_queue_ 

This entry is used to create a service. Associated 
with each service is a seg«e*it iut the- istojeafle hierarchy 
that is used to store the flMHi&talbtafcjofitfthB ,- server 4?rocoss 

and as queue of requests for ^t» iS«*pri#<MN ; 



declare create ^..mK^qjgvmaL xJml/Q&l -i <* ar <*• » 
char(*), fixed binary, fixed bin (35)); 

call create - service_q«#tte i _ fse*vice_na«e, 

initial.. procedure, nu«ber_of_servers, status) ; 

1) service_naae The na«e of the service. It is the 

vparthna*e of .- *&fe .««&«&o*»> q*eu% in the 
aultiCfS sfeqria^jt, s,^it^|*o(input) 

2) initial procedure The first issaeftftitse <sa4A*d ^hen the 

s*rTice*s #ro«j^» is «re^t^. (input) 

3) nu*bet of servers The »axi»tt» l BJMri*sr of processes. th*t 

"" V are to fee tava>]§**le simultaneously for 

the service,, fifcpwt) 

4) status Standard status code. Is normally 

zero, (output) 
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Name: f inancial_system_error_table_ 

This is the data base in "error -table" format for 
status codes from the financial system. Their meanings are 
generally obvious from their »*•#»* „ * fl * .status code 
returned is zero if the subprocedure completed its task 
normally. 

account_na me_ invalid 
to_account_ invalid 
fron_account_in valid 

An account name specified, in Mie parameter 
list is invalid. If tfaa calliit# pc<*$ran is not 
permitted to know that an account exists, the 
status code for invalid acco«m%^ *AH be igdtven 
even if the account is otherwise valid. 

account_already_exists > 

Attempt to create a new account with the same 
name as an existing account. 

no_ovner_access 

no_clerk_acc€ss 

no_access_to_transaction 

no_paynaster_access 

no,, r ec e i ver _ ace msa 

no_access__to_service 

The user does not have %fce iappropria>t» access to 
complete the reguest. 

transaction_not_found 

The specified transaction cannot be found in the 
given account. 

transaction_alr eady_closed 

Attempt to close a transaction that is already 
closed or to change the amount being reguested 
after a transaction has been closed. 

area_too_small_to_return_data 

The area specified for the return of the data 
structure is too small to contain all of the 
data. The initial portion of the structure 
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containing the size of the rest of the structure 
will, however, be filled ." ; 4» ; 90rat$wti the aiser -mi 
call the entry again with an area of the 
appropriate size. 

ar ea_too__s»a ll_-to_ret»TB^si2e 

The area con Id not even contain the header of the 
structure. The user should supply a new area and 
attew.pt to call the routine agsaiiifv -„. ^ b 

service_not_found 

The specified service cannot be found in the 
directory hierarchy. 

BeTVice_queue_ftfll 

There is no rooa left in the queue of reguests 
for the service. 



servi ce_out_ef _ order 



The service is unavailable for an unspecified 
reason. 



insufficient balance 



The balance of the specified itmm-tm insufficient 
to satisfy the request. 



Service_request_not_fdund 



The specified service request could not be found 
in the service queue. -?, >■•;■> 
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Naae: get_account_status__ 

This entry returns a couplets i statas of an account. 

Osage 

declare get_account_status_ entry ( char(*) , pointer, 
pointer, fixed bin (35) ) ; 

call get_account_status_ (ac«dttBt_naBie, area.ptr, 
statas_ptr, status) ; ; / 



1) account_naie 

2) area_ptr 

3) status_ptr 

U) status 



The naae &t t^# aCC^Wit whose status is 
being requested, (input) 

The area in #*£«& «H# Status is being 
returned, (input) 

Pointer to the structure within the 

area contaiaiifg the status;. The 

structure ^ is described in 
"account_status n . (output) 

Standard fittancial systea status code. 
This is zero if. the reguest completed 
noraally. (output) 
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Hap e: get_payBent^status_ 

This entry is awd to r«tri»i« iafcffi»tion froa a 
transaction record. To get this information, the subscriber 
■ust have either access to the transaction or clerk access 
to the specified accoant. 



Psaqe 



declare get_peyaent_statas_ (char (*) , b4.t{72) # fixed 
decimal (15, 2) , fixed decieal<15,2) , fixed 
decimal (15,2), fixed binary (71), bit(1), 
cbe*<**# char (*) , fixed binary43$) > ; 

call get_payeent_status_ (accouat_naae, 

..;t«a»s««tieBlii#.f : ..^t anoua^ne^afsted;, 

aaount^authorizftd, aaoent,paid_sofar, 

payaent_date, froa_account, to_accoent, status); 



1) account_nane 



2) transaction_id 



The nane of either accoant containing 
this transaction, (input) 



The onigue identifier 
traasartioat . 4iapat) 



for this 



3) aaount_ requested The aaouat of payaent that has been 

regnested. (output) 

ft) aaount^authorized The aaouat, of payaent that has been 

authorized, (output) 

5) aaount_paid_sofar The aaonnt that has actual been 
~ "" transferred to the receiving account, 
(output) 



6) payaent_date 



7) open_indicator 



8) froa_account 



The date on which the payaent 
authorization aatures. That is, the 
date the authorized aaoant is to be 
transferred to the receiving account, 
(output) 

If the value of this indicator is 
• 1»b, the account is still opes. This 
aeans that the aaoant being requested 
is subject to change, (output) 

The account froa which payaent is to 
be transferred, (output) 
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9) to_account The account that is to receive 

payment. This may be blank if it has 
not been specified yet. (output) 

10) status Standard financial system status 

code. Value is zero if data returned 
normally, (output) 
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»a* e; get_transactioft_status_ 

This entries returns the status of a transaction. 

declare get transacton status (char(*), bit (72), 

ptr, fixed bin~(35)); 

call get_transaction_status__ (account_naue, 

transaction_id, transaction_ptr, status) ; 

1) account_naue The naae of an account containing the 

transaction, (input) 

2) transaction id The unique naae of this transaction. 

(input) 

3) transaction^ tr Pointer to a structure described in 

"transaction_status" in which the 
information is returned, (input) 

4) status Standard financial systea status code. 

Is zero if request coapleted normally. 
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Naae: list_accounts_ 

This entry permits a ustx to get a complete list of 
accounts he cvns. 

SS^ae 

declare list accounts {pointer, pointer, fixed 

binary (35)); 

call list_accountsr_ (area_ pointer, list^ointer, 
statasT; ~ 

1) area_pointer Area into which the list of accounts is 

retuned. (input) 

2) list^pointer Painter to structure containing list of 

accounts. The format of the structure 
is: 
declare 1 accounts based iiist^pointer) , 

2 - nuabfer^of ^aejp^nnts fixed binary, 
2 account_na»»s 

(* refer (au«ber_of_accounts) ) 

■**fc»rj«torj§3^rt~t r v •;.,■-.:■ . 
(output) 



3) status 



Standard Sultics status code. Is 

normally zero, (output) 
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Wan e: list^pending^reguests^ 

This entry ret urn* a list of §U< ttfaeftsi a user has 
pending for a given service. srw^ 



Osage 



declare list-peaaingjr49e|a«*l* -> eatry (char (*) , 

pointer, "pointer, fixed bltt^t5H ; 

call lis*_p»pdiaq^regu*Sit«o Ui £ i{serviee_naae f 

area ^pointer, reguest_pointer, states) ; 



1) serrice_naee 

2) a rea jpoi n ter 



The «a»e* of t hawser vice for ehaeh the 
regues*ts are* te» fee listed, (input) 

area in vhich tJve : returned list is to 
fee allocated^, fivpat) 



3) request_ pointer Pointer to - s*ia«*»re «* the following 

f^oiciat i»**fe*Nv *he list of requests is 
returned: i^f/oao.. <: 

declare 1 requee*- list based (request_pointer) , 
2 nuabet_re#«e«fear If ized binary, 
2 request (* refer (number requests) ) 

flawed l&aijESdffn; a-----s.re ff 



4) status 



(output) 

Standard Bui tics status code. 
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gage; nake_payaent_ 

This entry is used to transfer aoney between two 
accounts without a prior' request fox payment. This means 
that there is no requested pay sent aaount associated with 
the transaction. 



declare aake^paynent entry ( chmrr<*} , char (*) , 
bit (72), fixed dec (15,2) £i :;ctar{*) , fixed 
bin (35)) ; 

call ■ake_paya«nt_ (frse^accouttt, to_account, 

transaction_id, aaount, description, status) ; 



1) froi_account 

2) to_account 



The account froavqwhljch the aoney is to 
be transferred, (input) 

The account <tx> ktoiscki the aoney is to be 
transferred, (input) 



3) transact icn_id The ideto<^dE*er x for the record of this 

payaent. (output) 



4) aaount 

5) description 

6) status 



The aaount atf aastey to be transferred. 
The description of this transaction. 

Standard status code, (output) 
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gang: request_service_ 

This entry is seed to request a service. The internal 

£ orna t of t he parameter' f 4*ixl e wiccitms, a*corddng to the 

service* ■' ?.- .. ■ "■ ■"',;»,'; :'/< .": :..->?.<-u. :■•-■. -'-./:!/" 



ossag 

declare request service, entry ( char(*), fixed 
bin(71) , ~ char<*) , fi**fl bin(7t) , fixed 
bia(3S)} ; f --?- ;,s i* 

call request_service_ (service.saae, transaction_id, 
paraaeters* r«g»est^id, Jrtaitpa|.^,^.s- 

1) service_nane Vane of the service being requested. 

2) transaction.id The identifier for the transaction 

r record <tto immmtA ££& billing purposes. 
Ift?:.«oJte dtffernittl dhraasact ion is to" be 
associated with tke reqaest, a value of 
,; zecoa is^asjamft^f (^fnt) t\ __-.- : ; .-■■•.. .::■..-., 

The paraaeters for the request. The 
^ifotEMcfe* o* thm^pajraaHters is define* 4>y 
the vendor of the service, (inpet) 

The oniqae idejct&fiiatr for the request. 

(OBtpttt} 

The standard Baltics status code. It is 
noraally zero, (oat ant) 



3) paraaeters 

4) reqnest_id 

5) status 
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Nam e: set_access_ 

This entry is used to specify the priviliges 
subscribers have with respect to an account* The subscriber 
nust have owner access with respect to an account in order 
to set access. 



Usa.se 



declare set_aceess_ entry f Char(*)#.1 like 

access_structure, fixed binary (35) ) ; 



call set_access_ 
status) ; 



(account_naae, access_ structure. 



1) account_naae 



The naae of the account for which the 
access is being specified, (input) 



2) access_structure Is a list of subscribers and their 

access with^^spect to* an account. The 
forn of the structure is: 



3) status 



declare 1 accesses tructure, 

2 length_of_access_list fixed binary, 
2 access~list like 

accoant^st*ttts.access_list ; 
(input) 

Standard Hultics status code. Is 
normally zero, (output) 
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Wage: set_authorization_ 

This- entry sets the authorization ; parameters for a 
transactioa. It cannot set the jwmt^mziimtaiom^/mjtmwt '; to a 
value less than that already ^peddwithematiHi d*ffc«ospecified 
is reached, the specified aaoant will be transferred fron 
the "fron" account's balance for the transaction's unit of 
payaent. ^ 

The user east have paymaster access relative to the 
"fron" account to use this entry. 



2S3SS' 



,.:.L 

declare se ^authorization.. (char(*) , bit (72), 

chart*** fi*ed< biaipl)^!: fixed (360(15,2), 
filed bin (35) ); : 

call set_*e*borizatioB_ - (aeceuBt_Baae, 

transaction_id, aaouat, dd»te# status) ; 



1) account_naae 

2) transaction_id 

3) aaount 

4) date 

5) status 



The naae of an account containing the 
transaction* (ispa*^ r 



The unique identifier 
transactioa* (input) 



of 



the 



The aaount of payaent to be authorized, 
(input) ^ 

The date when payaent is to be aade. 
(input) 

Zero unless there is a failure, in 
which case it is the reason, (output) 



Appendix c 



Page 9% 



t/18/1% 



"., Jf^^-^-'^S^* 



*■ - -_ - . - " --'*-*. - 



MPH FUTlHCIiL SYSTEM SUPPLEMSMT 



B. Franks ton 



Hang: set_request_auount_ 

This mw&tjzmitmtt.hwkmamnk Y*-f-f«faa&tY repeated for a 
traasacttfMu It i* r.*alMPa»* ioag ***»Sa* ttaasaction Is 
open. Modify access is required on the transaction **» «*e 
this entry. 



asjafi _ ^ ^ : 

declare set r«squest~anoant (*a*r{*) , bit (72), fixed 
dec(15,2), fixed bin (35)); 

. call " -'''«M M c*4MMA^la«MUt£,t>^ J-^ ^£^account_naie, 

transaction_id, mount, status) ; 

1) account_nane ; : "The. aaa»©xM£*a* account containing the 

transaction, (in pat) 

2) transacticn_id The unique v- 4* ) of the transaction. 

(inpat) 



3) aaount 
ft) status 



Aaount of »pa^*«at being requested, 
(input) 

Standard financial systen status code, 
(output) 
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N^me: specif y_receiving_account_ 

This entry is used t>y a ▼ed&dor *he has been assigned a 
transaction to specify the aceoant to *hirh payment is to 
be aade. 

os^as 

declare specify receiving account »< entry (char (*)-, 
fixed biir(71) kL char<*> # f ix#d biM35i ) ; 

call specify_receiTing_accoont^ (account_nane, 

transaction^**, ree^ivdnig^aetfount, status); 

* ■ ~ •"» :. s ' "-■ 1, .. ;' -," ; ;. " " , L> 1 3D." JOB '<■' it 82 ."r 

1) account_na«e Name of the account containing the 

transaction, (input) a.;-- -s.- : 

2) transaction_id Identification of the trsaction. 

<• .-. " ."* (input) a ;■>_ 

3) receiving_account The naae of the account which is to 

receive pay Bent, (input) ( 

4) status Standard Huitics status code. 
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Name: transaction__status 

Structure in which the status of a transaction is 
returned by get_transaction_status_. 

Fo rma t "■.■*;m . --.?-■■ 

declare 1 transaction statss^ba suf*^ 
2 transaction_id bit (72) f 

2 paying^acffpuat ?fc#£4fft*c - " /*ctff©»a 3«ct V; 
2 receiving_account char (32), /* to acct */ 
2 aaottnt_reque6fe94efiX«dMd|$I3£#24l a?; 
2 aaount_paid_sofar fixed dec (15,2), 
2 a«ount"~aathorized fixed dec (15, 2) , 
2 payaent_date fixed bin (71), 

2 receiver.naae char (32) , /* for reference */ 

:L 2 op»»2l£aCfMtt4) *■-.'•: ^-.'.^ii^O" 

2 request change_access char (32) , 

2 description_length fj*«d 0iUarj<|5) ■»:> 

2 description char(* refer (description^length) ) ; 
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